chore(ci): retire the StackBlitz demo and the npm lockfile it existed for - #1469

Fixes #1231

Retires package-lock.json, the StackBlitz demo it existed for, and the gate that watched it — the 2026-08-31 ruling's branch 2.

Step-1 measurement: what the ruling asked for, and what was actually possible

The ruling's step 1 is "实测 WebContainers 能否以 pnpm 跑本仓". That measurement could not be performed from this container, and no weaker reading is being passed off as it. The egress gateway denies CONNECT to every host that could answer it:

So no WebContainer could be booted and StackBlitz's live documentation of its bundled toolchain could not be read.

What was measured instead, locally and for real:

1. The claim in .stackblitzrc and the README is confirmed on its measurable half — and it has grown a second, newer blocker. Against a scratch copy of this repo's package.json + pnpm-lock.yaml + .npmrc:

• npx pnpm@8.15.9 install --frozen-lockfile --prod --no-optional --ignore-scripts fails before the lockfile is opened:

  ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)
  Expected version: >=10.0.0
  Got: 8.15.9
  This is happening because the package's manifest has an engines.pnpm field specified.
  To fix this issue, install the required pnpm version globally.
  

  package.json declares engines.pnpm at 10 or above, and .npmrc sets engine-strict=true. pnpm's own prescribed remedy is a global install — the operation the README recorded WebContainers as forbidding.
• With that engines gate removed from the scratch copy, pnpm 8 still cannot read the lockfile at all:

  ERR_PNPM_LOCKFILE_BREAKING_CHANGE  Lockfile ... not compatible with current pnpm
  Run with the --force parameter to recreate the lockfile.
  

  pnpm-lock.yaml is lockfileVersion: '9.0'. The only escape pnpm offers is to recreate the lockfile, i.e. exactly the cold full re-resolve the current arrangement exists to avoid.

2. Even granting a pnpm 10 inside the sandbox, the demo's install shape does not port. The demo ran npm install --omit=dev --omit=optional; the --omit=optional half is there because better-sqlite3 cannot compile in the sandbox. With this repo's own pinned pnpm 10.33.0:

• pnpm install --frozen-lockfile --prod — succeeds (432 packages).
• pnpm install --frozen-lockfile --no-optional — fails: ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY Broken lockfile: no entry for 'lightningcss-android-arm64@1.33.0' in pnpm-lock.yaml.
• both together — fails the same way on vitest@4.1.10.

3. StackBlitz's own documentation, read from source rather than from memory. Their public docs repos were cloned over the anonymous git lane (stackblitz/docs at e45067ef, stackblitz/webcontainer-docs at 4770ebe5). They confirm pnpm is supported ("WebContainers natively support all the major package managers including npm, pnpm, and yarn v1") but state no version anywhere, and record that the Node version is locked with multi-version support still on the roadmap. Nothing on a reachable channel establishes a pnpm 10 or newer in the sandbox.

Which branch that selects, stated with its residue

Branch 2. Everything measurable points one way and nothing measurable points the other, but the residue is named plainly: the one fact that would flip this — whether today's StackBlitz bundles pnpm 10 or newer — is exactly the fact this container cannot reach. Shipping branch 1 on it would put an unverifiable claim behind a README badge, and unverifiability is the mechanism that produced this card in the first place: package-lock.json's only guardian was a hand-written gate, and the tree it described rotted anyway. Branch 2 is the only outcome that rests on no unverifiable premise. A maintainer with a browser can reverse it in one measurement and a small revert.

The gate had three references, not one

The card and the ruling name the CI step. There were two more, and both are load-bearing — each was ablated by putting the reference back and watching the gate go red:

Each ablation proved the mutation on disk (anchored grep count plus a changed git hash-object) before reading any result, and proved the restore by hash equality with the HEAD blob; git diff HEAD is empty afterwards. The same file also carried a prose paragraph naming package-lock.json and pointing at the retired gate as its dedicated guardian; that is corrected, and the byte figures it quoted were dropped because they had already drifted (221KB/320KB written against 260KB/397KB measured).

Verification

Run at 2a545293 with a clean tree, joined with && so one verdict covers all of it:

pnpm hygiene && pnpm hygiene:tokens && pnpm validate && pnpm typecheck
  && pnpm lint && pnpm lint:i18n-gate && pnpm build && pnpm exec vitest run

• ✓ source hygiene clean
• ✓ source token ratchet clean
• ✓ Validation passed
• ✓ i18n lint gate: 0 i18n/missing-* issues
• ✓ Build complete
• Test Files 154 passed (154) · Tests 3259 passed | 1 skipped (3260)

That is this repo's whole pnpm verify chain, so nothing is narrowed.

Scope

package.json was not touched — it belongs to #1376's chain, and neither branch of the ruling required it. The five stalled dependabot PRs (#585, #658, #1058, #1178, #1179) were not merged, rebased, re-run, commented on or relabelled. #1225 tracks advisories in the StackBlitz install tree; under this branch that tree ceases to exist, and that card is left untouched for the seat to redirect.

.github/labeler.yml is outside the file surface this was dispatched with. It is included because the deletion makes test/labeler-config.test.ts fail without it — a required consequence, ablated above, not a discretionary tidy-up.

Generated by Claude Code

Generated by Claude Code